dec :: decus :: pdp8 :: 12-bit SIG :: fiche :: 12-bit SIG newsletter#13 Jul75

'PS 8".

53 DECUS OS/8 SiG NEWSLETTER

DECUS

July Number 13 1975

Contributions and correspondence should be sent to:

Bob Has singer, Coordinator

OS/8 Special Interest Groin?

c/o DECUS

146 Main Street

Maynard, Massachusetts 0175^

REVIEW OF THE SPRING PECOS SlftffPSIOM - QS/8 Special Interest Group Activities

Most of the material in this item comes from a report written by Doug Wrege
for the call for papers for the Fall U.S. Symposium.

An increased effort was made at the Spring Symposium to coordinate panel dis-
cussions and workshops following groups of papers in a given area. There was
a time-sharing panel, a high level languages workshop, traditional PDP-8 family-
workshop, and the familiar OS/8 Special Interest Group meeting. There was a
great deal of interest in time-sharing or multi-user or foreground/background
type applications, both West Virginia University and Georgia Tech reported on
work in this direction.

In the languages session a new rutermediate level language called BLIP was
discussed. It is somewhat like a simple version of BLISS-11. It gives an
intermediate level language between something like FORTRAN and something more
like Bfili8. The generated code is B&L8 code. There was also a great deal of
discussion and interest in OS/8 FOBTRAN IV. Enough to possibly warrant a
separate session for it at the next meeting. There was a Traditional Products
session which consisted almost entirely of pre H)F8e users of FDP8's and
PDP12's. A very active and interactive session with Bob Reed from DEC Tradi-
tional Products was the result. There was much interest expressed in forming
a Special Interest Group to represent the traditional computers within DECUS.
It has been concluded that for the moment this group can be a part of our OS/8
Special Interest Group because almost all current Traditional Products are in
the 12 bit families. Therefore, I have included the first input from N. S.
Kendrick who has been asked to act as coordinator for these activities to get
the group going. Old timers will remember his activities going back many years,
to the days of the original PDP-8. We plan to initially publish this informa-
tion in our Newsletter, along with all other PDP-8 and PDP-12 related
information. The trend seems to be away from strict concentration on OS/8 and
more towards representing the entire spectrum of PDP-8 and PDP-12 problems and
interests. Your inputs on this are solicited. Is this trend go, bad, or does
it make no difference to the future strength and viability of the OS/8 SIG?

July 1975 Newsletter

Before leaving for Miami -we were afraid there would be vary little equipment
from the PDP-8 and PDP-12 family. We knew only that we would have available
a small PDP-8e with TD8e DECtapes for the sake of tape duplication, That
machine arrived but much to our surprise Traditional Products arrived with a
newly configured H>P-12 that they used to announce that the PDP-12 had become
a Traditional Product and that they intended to support it. The users found
the 12 very useful. After hurried calls back home we got LENCtapes sent to
Miami (no one had thought to bring any) so that we had some software to run
on the 12.

A COS-310 system also appeared. S ome of th€; DEC system software people and a
couple of users got together and worked up s. demonstration of a very smal I
network using some of this hardware. A pair of high speed serial interfaces
appeared and were plugged into two of the K»P-8 f s to connect them. Some soft-
ware was installed on both machines to implement a minimal. "DECNEF" between
the two machines. BTS8 was run in both maci&nes with CS/8 running in the
background in each case. The machine with only DECtapes utilized the network
to access one of the floppy disks on the COS-210 system and use it as its
system device. After that the interruptable TD8e DECtape handler called SD8
(see last Newsletter) was modified into an IJTS8 task and installed on the
TD8e system ajd it demonstrated its ability to utilize the TD8e DECtapes while
running under BTS8 and communicating on the network. Incidentally, this net-
work actually ran faster than the H)P-11 netiwork that DEC was officially
demonstrating at the meeting. The reported reason for this was that there
were seme sort of bugs in the PDP-11 system., but the PDP-8 software worked
first try.

HELP!

As you all know, this Newsletter is published too infrequently. The main
reason is that it's a lot of work. If I had a regular input of ready to use
items we could publish on a regular, frequent schedule. Individual items and
regular columns can be submitted. Anytime inhere is enough material that does
not require re-writing and editing to form "the nucleus of an issue I will add
what I can and get it to DECUS immediately.

There are a couple of guidelines to observe when writing articles for the
Newsletter.

1. The DECUS Board has a non-commercialization policy that requires
emphasis be on technical rather than commercial content. The Board
also requires that prices not be given. However, it is all right
to mention if a charge is made for an item.

2. Due to the high cost of printing and mailing we need to try to keep
Newsletter articles short. DECUS underwrites all the Newsletter
costs but as more SIG's form and publish Newsletters the DECUS Boards
will have to take closer looks at the iosts involved. If we all do
our part to minimize costs we can keep this valuable channel of com-
munication open and unrestricted.

#13
July 1975 Newsletter

OS/8 SIG GROWTH

I recently reviewed the SIG mailing list and found that we have srown to over
1100 members. J^re than 200 of the members are in Europe. The availability of
this information sorted by geographical area makes it much easier to help get
Local Users Groups going.

The membership list is considered confidential information by DECUS. Access
to it is restricted and requires a non-disclosure agreement but if you are in-
terested In forming a Local Users Group contact me and we will work something
out to get you the necessary information to get going.

FROM N. S. KEHDRICK, JR, - TRADITIONAL 8-FAM3XY S.I.G.

The interest shown at the Miami Symposium in -updating the older family of 8
products led to the suggestion of a SIG devoted to efforts to maintain program
capability across the product line. Considerable interest was also shown in
acceptable hardware modifications to the 8/e group. For the present, at least ,
it would seem advisable to operate as a subset of the OS/8-RTS/8 group since
these systems provide the main motivation for such work. I will try to serve
as a clearing house for this information and pass on a digest to Hassinger for
inclusion in these Newsletters. If those of you who tinker with the nuts and
bolts of the operating systems will pass along your results to me maybe we
won't all invent the same wheel too many times! (We may even come up with a
round one once in a while.)

Work in our laboratories at present is directed toward the following goals,
hopefully to be complete by the Fall meeting in Los Angeles:

1. Implementation of the BSW instruction on the plain 8 (can't call it
classic anymore) and the 8/1-12 group. The 8/1 seems to be very
simple from a cursory examination of the prints.

2. A complete re-do of the memory extension-time share module for the
8/e incorporating a more intelligent trap as outlined at the Miami
meeting. The design work on this is well under way.

3. Modification of the ETS/8 executive to make use of the new trap.
k. The trap modifications to the S/l-IC group.

Your suggestions and help would be appreciated.

I have recently received a communication from J. Floris Anthoni of The Nether-
lands on their MULTI-8 real time foreground/time sharing background operating
system which seems very interesting. As best as I can decifer Dutch his
address is Medical Biological Laboratory TNO, Lange Kleineg 39? P- 0- Box k5,
Rijswijk, The Netherlands. This is a new hardware/ software system similar to
some of the ideas discussed at Miami.

#13
July 1075 Newsletter

SWEDISH IQCAL OS/8 USERS (BOUP ACTIVITY

Lars Baliier writes me that the Swedish OS/8 LUG is trying to construct a
primitive library for primitive programs. What they intend is to construct a
simple circulation list of programs and routines which are mostly not docu-
mented to the standard necessary to submit to DECUS which might be for other
reasons not submittable to DECUS. These reasons might include such things as
authors wanting to get a reimbursement for their work, or because there is some
sort of bug in the program which makes it unsuitable for DECUS submission.
They are presently experimenting with an unsophisticated circulation list sorted
according to the DECUS category codes, and which includes information like pro-
gramming language, cost bracket for the program, standard of documentation, and
the author *s name and address. It is up to the individual interested in the
program to contact the author. They do not intend to do any kind of distribu-
tion themselves of anything except for the information on the list. This is a
good example of how a Local User Group can provide help for the users in an
area, and it also demonstrates how the Special Interest Group as a whole Can
help various users to exchange programs when they can't submit them to DECUS
for whatever reason.

APVA3S3CED OS/8 SYSTEM DEVELOPMENTS

Since the last Newsletter the hopes for DEC sponsored OS/8 development beyond
the currently planned maintenance update on OS/8, (which is supposed to include
MA.CREL and its loader) seem to have dimmed due to lack of support among the
various product lines at DEC, User interest seems to continue, however. It
may eventually turn out that the users will end up doing their own development
again if DEC doesn't get busy.

Just recently I received a note from Clyde Roby outlining some of his ideas
for such a new system. Clyde's suggestions include the following:

1. It should be OS/8 compatible at least for ASCII sources.

2. The directory should be expandable (or at least expanded) beyond the
present size.

3. The new system should be integrated into an RTS8 type environment.

k. It would require at least 12K 9 kK for tiie RTS8 part and 8K for the
new monitor. It probably could require l6K of memory as most people
can now afford that much memory with memory prices coming down the
way they are.

5. An RTS8 environment allows many nice features such as (a) there should
be a system task call tc get /put characters to any device. It should
be set up so that all devices weald have the same call to get/pat a
character. This would make for very device independent I/O. (b) A
spooling task may be inserted between the user call and the active
device driver ta.cz. to spool I/O. (Note that there has already been some
work done on a line printer spooler which runs in the present 0S/8-
RTS8 configuration).

oiuj t.rfiz> iAeWs-L.ex."oer

6. If the system were set up correctly an entire system should reside in
a .SV file. Users could make specialized systems for their own
different types of applications. They might he similar to the present
/Y files hut would he .SV files which would he "bootstrapped" too.

7. As far as command language syntax goes it would be nice to be com-
patible across DEC's main frame line as much as possible. (Note: DEC
is presently working on defining a new command language standard which
will he distinctly different from any of their existing command
languages. More about this later.)

8. SCAN and WILD (vis-a-vis the PDP-10) could be incorporated into the
RT38 part of the system as an overlay task. Users could then implement
some good programs by calling them via a system task call.

9. About security: As on other DEC software systems for the other main
frames there should be prog/'anmer/project numbers, passwords, and file
access -*ords (read only, deletable, write only, etc.) similar to
DOS-11, TOPS-10, etc.

10. The system should be as real-time as possible with an RTS8 type fore-
ground but where TD8e DECtape and floppy disks are concerned true real
time may be a luxury.

11. No time-share trap should be used! All system calls should be direct
to BTS8.

Clyde is trying to get his version of LPTSPL ready soon but he says the work
load at Georgia Tech is pretty heavy. Also, Clyde suggests there might be in-
terest in a special category in the DECUS catalog for RTS8 tasks. Does anyone
have any such tasks as yet and is there any interest in a special category of
this sort?

MJIffI-8

MJI37I-8 is a real time foreground/time sharing background operating system for
the PDP-8. Plojis Anthoni recently sent me a copy of a manuscript which
describes this system in over -view. He has been writing it over the last couple
of years or so. It has much of the same real time, multi-task capability that
RTS8 provides, and like RTS8 it also provides the ability to run OS/8 in the
background. What is different is Lnat the background OS/8 can be multi-user ,
that is tnere are multiple OS/8 ^o> > that are swapped in the background so that
you effectively get a time-shared 03/8 system plus a real time foreground
capability. One of the more interesting features of the foreground capability
is that there are swappable tasks which are kept in a sort of a library on the
disk and they ^re brought in when they are required. The most interesting
feature here is that they are not required to load into specific core locations,
as with the new version of RTS8 but rather the tasks are organized in a page
relocatable way which is very efficient and very simple to use. The system
allocates core dynamijally at the time that tasks are loaded, and it frees the
space used when the task terminates itself. I am hoping to be al.? e to get more
information on this system and tc explore what sort of plans the author has ::*or
making it available before the next Newsletter.

#13

July 1975 Newsletter

STAlffiARDIZING FOREGROUND IOT's FOR OS/8 IACKGROUMD PROGRAMS RUNNING UNDER
B3S8 AMD OTHER FOREGROUKD/BftCTCGROUKD OPERATING SYSTEMS

As more aad more foreground/background type software is written and becomes
available, there is an increasing need to agree on some sort of conventions for
assigning the IOT codes that are used to make calls to the foreground or
operating system. The same type of calls are presently made by the TSS8 (EDU-
system 50) software. These calls are similar to the type of calls one might
make to a larger computer's operating system, but they are implemented as
psuedo IOT's in the typical PDP-8 system because the instruction trap is
normally used to implement such a system and it provides the most eonvenitit
way to ccsmnunicate from the background program to the foreground. Presently
we have RTS8, MULTI-8 has been announced, OMSI is working in this area, EDUcomp
is developing a similar sort of system, and various people are writing routines
to go *?ith RTS8 and other similar environments. In each case arbitrary selec-
tions are being made by the authors for the IOT codes. Obviously in the future
there will be many conflicts unless we can agree on conventions. If you are
working in this area, or have ideas, please send them along and we will try to
coordinate «nd gain some sort of agreement on how to approach this issue.

CUSTOMIZING CCL FOR YOUR INSTALLATION

Lars Palmer has included in his most recent letter to ^.e some information about
how his installation has customized their version of CCL to suit their uses and
their mode of operation. He thinks that this sort of Information would be
useful from many different users as each installation has their own special
needs. His changes are as follows:

1. In their system (which is a disk system with a floating point pro-
cessor) their main software is FORTRAN IV. To optimise FORTRAN IV
usage they have made several modifications to CCL.

P.. The TECO and MIKE commands default to FORTRAN (.FT extension).

B. A call to FRTS on the .ID extension has been added to the system.

C. The default mode alt -mode in the EXECUTE command has been removed.
They find that It causes a lot of trouble: oecanse it leads to

(l) the annoying forgetting of file specifications with FORTRAN IV
and (2) he has had difficulties as mentioned elsewhere finding a
way to pass an alt-raode in the BATCH fila.

D. They have changed the order of searching for file name in such a
way that the EXECUTE command always defaults first to the .LD then
to the .RL and finally to the .FT extensions and then to the other
file name extensions that are normally checked. This means that
he gets the sort of operation that you would probably like best in
a FORTRAN environment. If a .LD file exists then it is executed
directly and so on down the line. If only a .FT file exists it
will be compiled and loaded and executed, etc.

#13

July 1975 Newsletter

E. They have modified the COMPILE and EXECUTE commands in such a way
that the default output- file is on DSK: . This means that it is
possible to do a COMPILE TEST followed by an EXECUTE TEST which
will pick up the compiled version, What is happening here is that
normally the default onput file for some of these commands is SIS:
rather than DSK: and in a system wher* these two names refer to
different devices, you normally can't do what you would like, I
find this true 5n my DECtape system in particular where the distinc-
tion between the two devices is the normal way of operating the
system.

2. They have found the DrLETE command is very dangerous, particularly in a
disk system where it executes very quickly. Files disappear- before you
have a chance to think about what is happening. This is even more so
where they have a 2hQO baud console on which the file names go by very
fast as they are output from the delete function of FOTP. Therefore,
they have included the /Q option in the DELETE command so that it always
forces you to answer "yes" or "jo" to each delete. In order to allow
for deleting in those cases where you are sure of what you want to do,
such as in a BATCH file, they include a new command which they call
KTTtTiX which works the wa_> the old version of the DELETE command works,
loug ¥rege f s newest version of DECsystem-8 has made a slight change to
the DELETE command also. Whenjou specify a delete of a single file
(i.e., no wild card specifications) he goes ahead and deletes the file
in the normal way. But when you specify wild card specifications so
that considerable numbers cf files might be deleted, then the /Q option
is automatically forced.

3. The DATE command has been implemented in such a way that it runs a
special BASIC program which writes a TECO MACRO which includes today's
date. Then when you do a TODAY file-name, TECO will do the normal EB
on the file but with today's date inserted as a comment at the top of
file. The default comment character is a C as in FORTRAN code, but any
comment letter can be passed to the file. He includes a listing of the
BASIC program with his letter. If anyone is interested in it let me
mow and I will send a copy. To make this work he has to inhibit the
chaining test in BASIC. This is done by changing location 7001 in the
BASIC save module to 7000 (NOP) with this change the program will work
in all cases except if DATE is given under BATCH.

k. As mentioned under the paragraph on EXFTP Lars has implemented UPDATE
and MOVE commands which are very convenient in certain situations.

5. Lars uses an off-line paper tape punch where paper tape is punched which
is read in for revision later on the computer. They have a special
handler which does some editing on the tape as it is read in. This is
actually a modified version of the new 2-page teletype handler. To
simplify reading the data in from the paper tape reader they have
implemented a new command FETCH which will simply fetch a file from the

July 1975 Newsletter

paper tape reader giving it the name which is the argument that goes
with the command. It will use the special handler by default. If a /A
or /B option is given then PIP will use the normal paper tape reader
handler.

6. Re has taken the PRIST command and arranged it so that it utilizes Clyde
Roby*s PRINTR program for formatted printing of files on the line
printer.

7. Lars has also implemented a DUMP command, which will output in octal
form. Doing DUMP A,B will output a listing of the differences between
files A and B. This is implemented using the program OCOMP which is
available from DECUS as 8-608.

EXPIP

Lars Palmer from Sweden has submitted a new version of his EXPIP program to the
DECUS Library. It is a PIP type program that has features that neither PIP nor
FOTP have. It allows wild card specifications for file name extension in
particular. It contains several features that are nice for people with two
DECtape systems that make moving files around more efficient. It has a command
that permits merging files which is sometimes very nice using wild card file
name extensions. There's an option to transfer files only if there is not a
file of the same name on the output device with a more recent or the same date
as the input file and there's au option to never transfer a file if there is a
file of the same name on the onput device. There is an option to remove the
input files from the input device after the transfer has been completed
successfully. Another variation on this is to transfer files only when there
is a vcre recent version than the version that exists on the onput device. The
Q, option as in FOTP gives you a chance to decide on each individual file and
you can specify today's date for the new onput file. The quals option lets
multiple copies of a file to be made. This means that a listing function could
be implemented to produce several copies of a file on the printer automatically
from one call. Lars says that using this program he has implemented two new
commands under OS/8 version 3 and CCL - these aie UPDATE and MOVE. These
commands do what their name suggests, he says. UPDATE will write new copies
of files on the onput device that already exist there in older versions and
MOVE will do what COPY does but after doing the copy it deletes the input file.
I find with a limited DECtape system that these commands can be very useful.

I think we have finally solved the problem the DECUS Library was having with
EXPIP also. There have been difficulties with tapes from Lars* part of the
world coming through unreadable. Something has been happening somewhere along
the line to some of them but the current tape seems to be all right .

SOFTWARE UNDER DEVELOPI-SNT BY LARS PAIMER

Lars Palmer has written about several routines that he is working on. He hopes
that some of them will be released to DECUS in the future when he has a chance

#13

#13
July 1975 Newsletter

to document them properly. In the meantime, he has sent along a short summary
of what they are about and if anyone is interested they can contact him.

1. A small routine BGET and BRJT which allow you to utilize the 36 in-
dividual bits in a floating point word under OS/8 FORTRAN IV. The
routines are called exactly the way CGET and CPUT are. This
routine allows you to use a very large number of logical variables
as in a program such as Conway's game of life.

2. A small routine called FILE SIZE which will communicate to the
FORTRAN 17 program the size of the different files given at run time.
It will also cell you if a certain file number is associated with
one of the internal, handlers built into the run time system.

3. A number of small routines modeled on the PDP-12 routines available
in the FORTRAN IV Library but written for the PLP-3e digital inter-
face. Utilizing the routines in a special patch to the run time
system he has also implemented the possibility of reading command
decoder switches into the FORTRAN program- This makes it possible to
modify the action of a FORTRAN program in a BATCH file. At the moment
the communication is via the MQ register but Lars says that it's a
trivial modification to change this.

Another program that Lars has functioning which he will make available to DECUS
as sooa. as the documentation is produced is a program for filling in forms on a
high speed VT05, a blank version of the form is written and kept in a file.
The program displays the blank form on the VT05 face which then is filled in
appearing write protected in all places except the fields which are to be filled.
The filled in information is then written to a file and can be used for further
editing. He says this gives a very fool proof way of inputting data to be used
by other programs. The program is written in FORTRAN H and requires 12K and a
high speed VT05- A disk is an advantage but not necessary. However, it must
have a second logical OS/8 device besides SIB:.

SSP THS SCIENTIFIC SUB-ROUTINE PACKAGE

In the last few months there has been a lot of interest in the Scientific Sub-
routine Package which is available on many computers. I understand it has been
placed in the public domain by IBM. Apparently it exists in at least two
different forms. One for the IBM 1130 and one for the IBM 360/370 family.
Apparently the 1130 version is a subset of the full version. Dr. Arthur
Stiennon has written to tell me that he managed to convert the 1130 package for
OS/8 FORTRAN IV successfully. He is planning to make his work available for a
nominal fee, I believe. Tom Maclntyre also indicated that some work had been
done in this same area at West Virginia although he has not mentioned any plans
to make x.t generally available. Since then I have been talking to Dave Todd,
who is heading up the efforts of the PDP-10 Main Frame Group to improve the
PDP-10 part of the DECUS Library. As it so happened, Dave also is the most
recent submitter of the SSP for the PDP-10. This is listed in the DECUS catalog

#13
July 1975 Newsletter

as 10-101a now. The difficulty with that package for the rest of us has always
been that it was only available on l/2 inch magnetic tape in FDP-1G FAILSAFE
format so it was not readily accessible. Dave has converted the package to 5
PDP-10 format DECtapes for me. I have converted the files to OS/8 format DEC-
tapes (six of theal) and I have fixed some of the more obvious compatability
problems. If I can find enough DECtapes I hope to submit the package to DECUS
later this summer.

HEWS FROM OMSI

Rusty Whitney from OMSI recently wrote me asking to mention in the Newsletter
that a routine for reading BCD data from a half -inch MAGtape and also a routine
to handle the Xl8e plotter which works under OMSI's PS/8 FOCAL are both avail-
able from Harold Cronin, Code 602, Naval Weapon Center, China Lake, California
93555.

At the Spring Symposium OMSI also revealed that it has been working on a multi-
user OS/8 system. No details are available as yet and I understand there is
still development work to be done.

MATERIAL FROM. JIM CKAPUUHKt'TKS

Jim has sent along a couple of patches for the FORTRAN 17 run time system. One
of them allows you to control the INPUT ERROR condition which normally, when
detected, causes an abort of the program. When you are writing a program that
is designed to collect data from manual input and record it in a file this is a
bad feature of the system because any input format error can cause the program
to abort and then you end up losing all of the data that you input.

Jim also included a set of ODT patches which cause the FORTRAN run time system
to ignore both the default input format specification and spaces in the input.
He says that this allows truly free format input from the keyboard although it
does not adhere strictly to the FORTRAN specification. Together the two patches
make a nice data inpat package for keyboard input to FORTRAN.

Jim is in the process of making some changes to his version of TECO. He is
going to try to make it compatibxe with the DEC version. His work is aimed at
new features related to I/O that will make it more powerful than DEC's TECO.
He plans on such things as multiple input files, square brackets specified
length for the output file commands, and the ability to reset the input file to
the beginning. He will also allow a ":" to modify a file command so it returns
a succeed or fail code rather than giving an error. Jim is interested in
suggestions for changes or additions in connection with this work. Anyone
interested can reach him at Frelan Associates , P.O. Box 298, Menlow Park,
California 21*025. Jim has also included a fix for his program FUTIL which is
in the DECUS Library.

10

#13
July 1975 Newsletter

INFORMATION FROM REVEREND CHASE

Reverend Geoffrey Chase from the Portsmouth Abbey School wrote recently to mcke
a couple of suggestions and to pass on a coding technique which he has found
useful. First, he noted the error in the recent Digital Software News in a
patch to CBEF which was stated as a 701^ when it should be a 7012. Second,
Reverend Chase suggests that in the future DEC should do sca*eth:dag to make the
length of the string that you can pass to DECO using the MDHG cons-and longer.
Apparently when the SfflSKx command was designed no one anticipated the need to
pass longer strings, but it seems possible to do it.

Reverend Chase wondered about what the system does when you load a handler over
a previously loaded handler. The documentation seems lacking on this point.
As an example, if you were to load the LPT: handler over the DECtape handler
what would happen. It turns out that the system is clever enough to know to
delete all 8 entry points of the TCC6 handler from its residency table. Oddly
enough very few people really know that this is true. Apparently it was put in
the code back in the PS/8 days and it's been there ever since waiting till it
was needed. Reverend Chase has passed along a neat coding trick which many
people are not aware of for OS/8 FORTRAN II. As you know, OS/8 FORTRAN II in-
tegers are limited to 12 bits. Reverend Chase's coding technique gives a quick,
easy, fast way to take the integer part of floating point numbers which of
course can give a 6 digit magnitude. His demonstration program for computing
prime numbers also gives a quick way to get a vertical tab on the teletype.

NOTE FROM BILL KAUFMAN

Bill Kaufman from Mobil Research and Development has sent along information
which includes the following; A version of LEB8.RL which includes his software
to use the FDP-8e EAE for subscripting, integer multiply and divide, 27-bit
floating multiply and 23-bit floating divide (both using the standard FORTRAN
II format) . I/O device 1 obtains input from the batch file when batch is
active. Device 3 supports I/O to an ADDS 880 page buffered CRT, and devices
5 and 6 represent TC58 tape drives and 1. This handler writes 80,80 EBCDIC
with blocking of only records that are less than 80 characters.

Bill has also sent a slow running cross-reference program written as a TECO
MACRO for use on FORTRAN II programs which produces an interesting side-by-side
type of listing with both the FORTRAN and part of the assembly code listed.

LETTER FROM ALBRECHT LOMMEL

Mr. Lommel from Zurich has written to tell ug about some contributions he has
made to the library and to inquire about the possibility of the availability
of certain FORTRAN IV software. He has submitted four programs to the library.
First, "FASTAD" fast data collection, "W)ATA" for writing 12 -bit binary data in the
form of normal 256 word OS/8 blocks on the system device , "RDATA" to read this

11

#13

July 1975 Newsletter

data under FORERAN II and "ItxiO" the necessary I/O package for serving the
teletype. He says he would like to know whether any or the FORERAN IV users
has software for the ADOl-AP A/D converter and whether they have changed the
necessary modules in the FORTRAN IV package so that the real time capabilities
for data acquisition can he used with this type of converter.

SUGGESTIONS AND COMMHEES FROM DR. G. M. HODGSON

Dr. Hodgson recently wrote with several suggestions and ideas. Among others
he was interested in the idea of reviewing DECUS Library materials. He
suggests a review sheet for use in reviewing program that would include the
following information:

1. The reviewer's equipment configuration and version of the software
used to assemble the DECUS program.

2. The experience of the reviewer.

3- Problems found with the program when compiling, loading, starting
up, running, input /output, and accuracy results.

h. Restrictions found that are not noted.

5. Comments on adequacy of write-up.

6. Corrections, suggestions, patches, additions, changes to the program
or write-up.

7. Recommendation for retention in library.

He suggests that if this information is to be valuable it needs to come from a
broad base. Once a sufficient number of replies for a particular, program have
been received, a summary evaluation form could be prepared. It should indicate
how many persons had evaluated the program. This would be attached to the
program write-up. Once the review process was underway an evaluation sheet
would be sent out with each program when ordered. Periodic updating of the
evaluation would be included. Alternatively the evaluator could request his
comments be added to the summary sheet if he thought his problem with the
program was severe. If the evaluation indicated the program was to be eliminated
from the library, the author would have the option to correct and re-submit it.
An evaluation process might limit the number of programs submitted but
Dr. Hodgson thinks that they would be of higher quality. Some of this sugges-
tion parallels earlier efforts but perhaps with new emphasis it could be made
to work better than it did in the past. Some of his ideas may or may not be
popular. I think though that this is a good place to start on gathering ideas
on the subject and I'm still soliciting more inputs from everyone who has an
interest .

12

#13

July 1975 Newsletter

Dr. Hodgson also suggests that -we neec *\ process to alert users to updates of
programs. The cost of such a review process might increase the price of the
DECUS service charges, he thin 1 - However, he suggests that if the result is
a more reliable program that the higher cost would be offset by less time
spent getting the program to operate. This Idea ccmes up from time to time,
that of asking DECKS to find a way to alert people who have previously received
a copy of a program to updates of it. If you find that is something that you
think would be valuable for the library to try to do, let me know. It would
require considerable effort on the part of the staff that operates the library
and would most likely increase costs of operation of the library substantially,
but it's possible that there are enough users who want this service so that it
should be considered.

Dr. Hodgson has made several suggestions regarding improving the quality of the
write-ups that go with library programs. First, he would encourage including a
flow diagram with the listing so as to enable users to understand how the
program was designed and aid in locating the problems as they occur. And
second, if the program makes calculations the author should include a test
problem with its results. This will speed acceptance in checking the program
by the new user. I find flow diagrams are hard for some people to prepare and
some programs would be quite difficult to fully document in that way, although
certainly we should encourage it wherever possible. Do you think that requiring
flow diagrams is worthwhile considering that such a requirement might discourage
submissions? I certainly agree with Dr. Hodgson on the second point. Authors
should provide a generous supply of examples and tests that a user can run to
verify that the program is working and to see how it is intended to be used, at
least for some simple test cases. Many of the widely recognized OS/8 submis-
sions *s the library have such examples and I think the popularity of the
programs have been enhanced Vy the availability of the examples.

The final area that 3>r. Hodgson is interested in regards the problems of a new
user. Zi finds, for instance, that as a new user it's hard for him to discover
how PAIS difference differs from PAL3, PALD, or PAL10, or how FOCAL 8 differs
from FOCAL 1968, FOCAL 69, or FOCAL W, or even how OS/8 differs from PS/8.
Also learning things such as the difference between a PDP-o^and the earlier PDP-
8 * s . He needs to know what sort of software d: f f erences there are between the
machines. He says that he's not aware of any source of this sort of informa-
tion although he suspects that some of it might be available in a DEC training
course, but in *rany cases people don't get to go to those training courses
because of the way they purchase their systems, or because they aren't the first
person to use the system, and the training credits have been used up. Basically
the problem here is help for the new user. This seems to be an area that the
Special Interest Groups can help with considerably. What we could to is to ask
for volunteers in various parts of the country to offer a little bit of help,
perhaps on the phone, to new users who need it and to make information available
to new users as to who the volunteers are who will give thep advice and answer
their questions. It seems that this is useful judging from the experience of
other user groups. Supposedly DEC software support gives this kind of help but,
in general, it doesn't work out too well because the software support people
really don't seem to know that much about OS/8 either. As we hopefully build
up some Local User Groups within the OS/8 Special Interest Group they could be

13

#13

July 1975 Newsletter

focuses for this sort of help. If we get some volunteers we may be able to
name a HELP coordinator and that part of the OS/8 SIG might choose to sponsor
or organized a tutorial session at each DECUS Symposium to help the new users.
This is now being done in the case of the PDP-10 sessions, for instance.

NOTE FROM I. M. TFJgPLEION

Mr. Templeton has sent a short note which I will attach to the Newsletter
which he thinks may be of interest to OS/8 users who have a simple cassette or
tape unit for backup storage. The device he refers to in his article is a
Progressive Systems "ZIPPER" cassette unit for which he has record and replay
device handlers available also.

SHt«s FROM. IAR3 PAIMER

Lars Palmer has written with a summary of some SHl's that he had submitted to
F^C from time to time- He has not received answers to these SFR*s.

1. It is impossible to pass an alt-mode (dollar sign) from the EXECUTE
command under BATCH to a FORTRAN IV* program. This is a restriction
of the system which DEC has ansvsred but Lars is not satisfied with
their answer. He says that it means that it is impossible to run a
FORTRAN program under BATCH which requires file input. (Note: Check
Digital Softwave News, April *75* for possible solution.)

2. Certain restrictions exist in CREF when it is used with RALF input.
In RALF it is possible to have a symbol followed by a comma in places
where it is not the definition of the symbol. CREF misinterprets
this and will take the latest such reference to be the defining of
the variable.

3. There are some problematic restrictions in RALF. Certain codes will
not assemble properly. In some cases RALF will assemble a two-word
reference when it should assemble a one-word reference. It will also
sometimes give a redefinition error when there is no redefinition in-
volved. He has sent an SPR on this question but has not received an
answer. (Note: Some of this problem may be explained by an obscure
note in the 03/8 Handbook at the bottom of page 5-22. There they tell
us that the location of the base page via the BASE psuedo op and the
location of operands using 0RG= must be defined in the coding before
an FPP instruction refers to them. When this is true then the short
form of the instruction is assembled, rather than the long 2-word
form. Essentially this seems to mean that all of your variable
storage wants to be defined and your base register ?»rea wants to be
defined before the code that references it. This "feature" of RALF
can be most puzzling to a programmer who is accustomed to an assembler
like PAL8 where it doesn't matter whether the symbol is defined before

Ik

#13

July 19*75 Newsletter

or after the instruction that refers to it. It's particularly surpris-
ing because the information that gives you the clue to what is going on
is so well hidden in the documentation. Of course this is true of many
aspects of HALF and I hope we can encourage DEC to do something about
that.)

k. If, by mistake, two inputs files are defined to the FORTRAN IV compiler
(when the first one is the only one required) the compiler halts. The
solution is a simple patch which follows;

Gi7h/XXXX T7$$
6^33/1255 127^

5. Lars has problems with the FORTRAN n loader which refuses to load
properly if there is a software core size set in the machine. As
OS/8 BATCH sets the software core size equal to the BATCH field it
means that he cannot do a FORTRAN H load under BATCH at the present
and he does not understand why. (Check Digital Software News for
possible answer.)

SER REGARDING FORTRAN II LINKING LOADER

This SHI was submitted by Albrecht Lommel the 20th of March 1975- The problem
is that a FORTRAN program which runs under OS/8 version 2 correctly does not
run with the new release - that would be OS/8 version 3. The source of the
progr&a has lieen compiled and reassembled under the new software . The diffi-
culty it* that the new release cf the loader does not seem to load the program
correctly. The new program requires more than 8K and the difficulty seems to
be that the loader is not correctly recognizing more than 8K of core. He sai's
that this version of the FORTRAN II loader was not able to form a correct core
control block. It was necessary to get a map to insert the explicit arguments
for the monitor SAVE command to get a correct saving of the program on the
system device. This seems to continue to be true in spiie of the fact that
the patches for the FORTRAN H compiler SABR and LOADER published in the
February 1975 Software News have been made. (Note: Digital Software News,
July '75 FORTRAN II #3 might fix this.)

SHI REGARDING DIFFICULTY WITH OS/8 BATCH ON A 32K SYSTEM

This S'tft was submitted on the 29th of April, 1975. When OS/8 BATCH is run on
a 32K system it sets the software core size to the top of field 6 rather than
the top of field 7. The first problem is that BATCH cannot utilize the entire
32K system but will only utilize 28K of such a system. The second problem is
that when BATCH terminates it leaves the software core size set to the top of
field 6 rather than restoring the full 32K capability of the machine. Thus,
the only way to recover the use of the rest of the core is to use a CORE
command to regain the last space. This must be done manually. The CORE com-
mand is illegal under BATCH.

15

#13
July 1975 Newsletter

I have gust received an answer to this SPR dated 26 June 1975 (9 weeks!). It
given a temporary fix. If anyone needs it let me know*

SPR REGARDING A BUG IH THE OS/8 FORTRAN IV LOADER

I submitted this SPR to DEC on the 29th of April and received an answer very
quickly. Apparently the article that they sent back as an answer was already
in preparation at the time the SPR was received. The answer is scheduled to
be published in the July, 1975 Software News.. The OS/8 FORTRAN IV loader
version 22 does not obey the software core size correctly.

SPR REGARDING DOCUMENTATION OP OS/8 FORTRAN IV STATEMENT FUNCTIONS

This SPR was submitted on the 29th of April, 1975 and no answer has been re-
ceived to date. The OS/8 Handbook states that arguments to statement functions
are "dummy" arguments and then goes on to say that they should not be refer-
enced outside the statement functions. Actually what happens is that the
arguments are not what we would commonly think of as dummy arguments. The name
used refer to the same "variable as the name -refers to in the rest of the
program. In other words, the "scope" of the arguments includes the entire
program rather than Just the statement function. This appears to be inconsis-
tent with the FORTRAN IV standard. You should be careful when using statement
functions to make sure the "dummy argument" -variables are referenced no where
except in that statement function, or else you should check the generated code
to be sure that nothing is happening that you had not anticipated with respect
to conflicts in the naming of your variables and their storage.

SPR REGARDING THE FORTAN IV COMPILER MAKING iiERORS WELLE COMPILING STATEMENT
FUNCTIONS

This SPR was submitted 29, April 1975 and no answer has been received to date.
The FORTRAN IV compiler seems to make compilation errors under certain condi-
tions when it is compiling statement functions. In an example that was included
with the SPR there was a statement function iefinition which included a call to
a function from the library. One of the arguments given to the library function
was an argument that had been passed to the sub -routine. If you study the
compiled code very carefully you discover that the internally generated location
of tags gets confused and the program ends up branching to an incorrect location.
It appears that this problem can be avoided by setting a local variable equal
to the argument passed to the sub -routine giving you a local copy of the
variable. In this case it appears that the compiler does not make the same
error.

SPR REGARDING THE FORTRAN IV COMPILER

I submitted this SPR to DEC on the 29th of April, 1975 and no answer has been

16

#13
July 1975 Newsletter

received as yet. This SPR involves a very subtle problem that took many hours
to track down. Under certain conditions the OS/8 FORTRAN IV compiler generates
code involving EXTERNAL type variables incorrectly. When the EXTERNAL type
variable is passed as an argument to a sub-routine, code which uses the value
of that EXTERNAL variable may be incorrect and cause the system to blow up when
the EXTERNAL routine is called. The conditions under which this happens are
when the compiler places the storage for the external type variable after the
sixth variable in the base register area. Those who have looked carefully at
the assembly code generated by the FORTRAN IV compiler, and who understand how
the FPP code works know that in sub-routines six variables are placed in six of
the first eight base registers and then the balance of the variables are
pointed to by the registers above that, the difference being that the FPP can
use the first eight registers in ways that it cannot use the rest of the
registers. For this reason, the code that references the first eight registers
works differently than code that references the other register-. The compiler
allocates those first six registers first for arrayed type variables because
those are the only registers that can be used to access arrayed type data.
And, then after all of the arrayed type variables are taken care of then the
compiler starts taking simple, undimension variables, in order that they are
declared in the argument list. In order to avoid the problem that this SPR
reports it seems necessary to have the total of the dimensioned variables
named in the argument list, plus the number of EXTERNAL type variables total
no more than six, and the EXTERNAL type variables should come before any other
nondimensioned variables in the argument list. If you think you have a problem
with this and you don't see an answer to it from DEC but you don't really under-
stand contact me and I will try and make it clearer.

17

£13

OPERATION CF BLOCK-ORIENTED, NON-FILE-STRUCTURED
STORAGE DEVICES UNDER OS/8

I. M. Temple ton
Division of Physics
National Research Council of Canada
Ottawa, Canada, K1A ORb

It appears that the most satisfactory way of sensing an
end-of-file condition on playback from a block-oriented, non-file-
structured device is for the data to terminate before the playback
buffer is filled. The rest of the buffer is then filled with zeros
and a non-fatal error return taken. This approach necessarily rules
out use of the /A (Ascii) or /B (Binary) modes under PIP. except for
very short files, since the playback buffer is larger in both cases
than the record buffer. This results in automatic termination after
one output buffer is replayed.

The /I (Image) mode is not subject to this limitation since the
size of both record and playback buffers is the same (640Cg words,
or 13 10 OS/8 blocks). In this case, however, another problem occurs
if the stored file is any multiple of 13 i blocks in length (e.g. CREF.SV) ,
since no unfilled buffer end-of-file condition can occur. The system
then continues to read subsequent files until a terminating condition
is found. This problem can be overcome by artificially increasing
the size of any such file by the use of the /l~n option under F1P.
The command *CREFA.SV<CREF.SV/I-16 creates CREFA.SV, 14m blocks in
length, which can be recorded and replayed correctly with no change
in performance ,-

18

#13

/"INPUT ERROR" CHANGE FOR FP.TS PALS-V9B 06/3C/75 °AGE I
/"INPUT EPPOR" CHANGE FOP FPTS

/BY:

/ JIM CPAPUCHETTES

/ FRELAN ASSOCIATES

/ P.O. BOX 298

/ MENLC PARK* CALIF. 94025

/ THIS PATCH FOR VERSION 3 CF FP.TS CTHE RUN-TIME

/ SYSTEM FOR OS/S FORTRAN IV) CHANGES THE ACTION OF

/ AN INPUT ERROR C ILLEGAL CHARACTERS IN THE INPUT

/ STRING) WHEN THE INPUT DEVICE IS THE TELETYPE AND

/ THE LIBRARY FUNCTION "CHKEOF" HAS BEEN CALLED.

/ UNDER ALL OTHER CONDITIONS* THE "INPUT ERROR" MESS-

/ AGE IS OUTPUT* FOLLOWED BY AN ERROR TRACEBACK AND

/ ABORT TO OS/8.

/ USAGE OF "CHKEOF" WITHOUT THESE MODIFICATIONS

/ IS DESCRIBED ON PAGES 8-50 AND 3-51 UF THE OS/5 HAND-

/ BOCK. AS WITH THE STANDARD VERSION* '"CHKEOF" MUST

/ 3E CALLED 3EFORE EVERY FORMATTED READ TO ALLOW TEST-

/ ING FOR THAT READ. AFTER THE READ* THE CONTROL VAR-

/ IABLE WILL INDICATE WHAT HAPPENED DURING THAT READ

/ AS FOLLOWS:

/

/ VALUE MEANING

/

/ - ERROR IN INPUT STRING (TTY INPUT ONLY)

/ 3 ALL INPUT DONE CORRECTLY

/ + EOF CCTRL-Z) FROM INPUT DEVICE

/

/ WHEN THE VALUE OF THE CONTROL VARIABLE IS NON-

/ ZERO* THE VALUES OF ALL VARIABLES READ SHOULD BE

/ CONSIDERED TO BE QUESTIONABLE.

/ SEE THE NEXT PAGE FOR A SHORT EXAMPLE PROGRAM.

19

#13

/"INPUT ERROR" CHANGE FOR FRTS PAL8-V9B 36/3 5/75 PAGE 2

/C PROGRAM TO TEST CHANGE TO INPUT ERROR HANDLER
/

/I 00

T -fRITE <0*1I00)

/l 13^

/

/

F Q r '?4AT ( * I MPUT VALUE S • / >

SUM=

/

DO 290 1 = 1* 100?

/2 I 3

VF.ITE C0*!110> I

• 1113

FORMAT <I5*2X$)

/

CALL CHKEOF C I ERR )

/

READ (0*1 1 20 ) VALUE

/I 120

/

/C IF

FORMAT (G14.6)

IERR = 9, ALL GK. IF I ERR < 0* INPUT ERROR* SO RETRY.

/C
/

/

IF IERR > 3* EOF CCTRL-Z) SO INPUT DOME.

IF (IERR) 210*293*330

/2 93

/

SUM= 5UM+ VALUE

AV ER AG = SUM / ( I - 1 )

/

VRITE C0 * 1 2 1 5 VJM* AVERAG

/121J5

FORMAT C0SUM - ^Gl^^** AVERAGE = f *G14.6//)

/

GO TO 100

/

EMD

20

#13

/"INPUT ERROR" CHANGE FOR FRTS PALK-V9B 36/35/75 PAGE 3

/OVERLAYING FRTS WITH THESE PATCHES

/

/ i. ASSEM3LE THIS SOURCE FILE WITH PAL8

/

/ .R PALS

/ *IWERR<INERR

/

/ 2. OVERLAY US IMG ABSLDR

/

/ .R A3SLDR

/ *DEV:FRTS.SV/I

/ *INERRS C THESE PATCHES)

/

/ 4. UPDATE FRTS VERSION

/

/ .ODT

/

/ 55 34/ 43 43 3043 C CHANGE " " TC "X ">

/ ?C

/

/ 5. SAVE NEW VERSION

/

/ .SA DEV:FRTS -757?> 1 2333-1 3777, 1 5403-1 7577 £233=2300

/DEFINITIONS FROM FRTS:

3316 VEOFS:-7= 16

33 25 EOLSV= 25

33 34 ERR= 34

3336 MCDF = 36

3133 HAND= 103

3143 LIT43= 143 /ACTUALLY A PAGE 3 LITERAL

3323 TTY= 323

21

#13

/"INPUT ERROR" CHANGE FOR FRTS

/ACTUAL CHANGES TO FRTS:

PAL8-V9B L 6/3 5/7 5 PAGE 4

/CHANGES TO IjCEjF INPUT CONVERSION ROUTINES

2/135 *2435 /'IMER* - OLD ERROR CALL, ILLEGAL CHARACTER

32435 5243 JMP INERl /GO A SAFE PLACE TO CALL NEV SRRO:

2443 *2440 / , INDCPT , +2 - TtfO DECIMAL POINTS SEEN

32443 4773 INERl > JMS I AINERi /CALL NEH ERROR - SAFER PLACE

2536 *2536 /'INE'*1 - T T ^0 "E"S SEEN

32536 5243 JMP IMER1 /CO CALL NE*.-J ERROR

2573 *2573 /'INESV+I - WAS FREE

32573 7433 AINERI* INERX

/CHANGE TO L INPUT CONVERSION

2633 *2633 /'LINGCH'+il - ILLEGAL CHARACTER SEEN

32633 4763 JMS I AINER2 /CALL NEW ERROR ROUTINE

2763 *2763 /'HC^'+l - WAS FREE

02763 7430 AIMER2, INERX

22

#13

/" INPUT ERROR" CHANGE FOR FRTS PAL3-V93 36/35/75 PAGE 5

/CHANGE ADDRESS OF INPUT ERROR CALL IN ERROR LIST
4614 *4614 /HAS 'INER* - ADDRESS CORRESPONDING TO
34614 7437 INERR / "INPUT ERROR"

/CHANGE LINK WORD TO •LPBUFE*
7371 *737 1 /AT END OF *LP3UF4' (PLAIN VERSION)
557371 7422 LPBUFE

/ADD NET-' ROUTINE AT THE BEGINNING QF THE LPT RING
/ BUFFER SECTION. REQUIRES THAT THE LINKS TO THIS
/ SECTION ALSO 3E CHANGED TO NEW 3UFFER START.

7403

*7430

07400

0330

INERX,

3

/SPECI

3T431

7203

CLA

37*32

1103

TAD

HAND

0743 3

1221

TAD

i-'TTY

07434

7653

SNA

CLA

37435

1016

TAD

VEOFSW

37436

7453

SNA

07437

4434

INERR.,

JMS

I ERR

07413

44 36

JMS

I HCDF

3741 1

3212

DCA

.+1

07412

7402

HLT

07413

7240

STA

37414

3417

DCA

I VEOFSW + 1

07415

6201

CDF

07416

1140

TAD

LIT43

37417

3025

DCA

EOLSW

07423

5600

JMP

I INERX

07421

7463

MTTY*

-TTY

7422

LPBUFE =

.

/NEW S

/SPECIAL HANDLING FOR INPUT ERROR

/IS THE INPUT THRU THE TTY?

/YES, HAS SWITCH BEEN SET?

/NOT TTY OR NOT SET UP
/TTY & SET UP* HAKE A CDF

/EXECUTE THE CDF TO THE

/ FIELD OF VARIABLE AMD

/ SET MANTISSA TO 7777*0

/ WHICH IS NEGATIVE.

/NOW SET 'E0LSV TO A SPACE*

/ FORCING REST OF LINE TO

/ SPACES CEOLINE* RESETS IT)

/NEW START OF BUFFER SECTION

23

#13

/"INPUT ERROR" CHANGE FOR FRTS PAL8-V9B 06/35/75 PAGE 6

3301 FIELD 1

/CHANGE TO 3>D INPUT CONVERSION ROUTINES CD. P. FPP ONLY)
6453 *16453 /'DIND'+l - DOUBLE "D"S SEEN
16453 5321 JM? DIMERR /GO TO MEV ERROR CALL

6516 *16516 /•DINER' - ILLEGAL CHARACTER IN INPUT
165 1 6 5321 JM? DIMERR /GO TO SAFER PLACE

6521 *I6521 /'DIDCPT'+2 - TWO DECIMAL POINTS SEEN
16521 4763 DINERRj. JMS I AIMER3 /CALL NEtf ERROR ROUTINE

6563 *!6563 /'DINESW+l - ? MS FREE
16563 7433 AINER3* IMERX

/CHANGE LINK WORD TO 'LP3UFE*
7372 *17?72 /AT END OF 'LP3UF7' CEAE OR FPP')
17 372 7422 LPRUFE

ssssss

24

Orwavvoje 4z> FETS *fo de£ecd~ de*ftxtt(4 d^ai^uf
poinJt tnpuJh cu*A 4s> ialty te$n&*e Spaces

2177 / 24#p 2S-71 ^ Cluuige ftterajfl : OjdcUfcss •-£

2S7i / xkxk 30t>4»b **DCA oo* -se+d^uif-fc #
2S7X / Xxk K 520CT } "STMp X«EFDO*- go -fo «*4 &ta*4

24*3 / 7t>H( 1Z001 *clA*~ ignore -fa*Ui*g fcUnUks

SS3S / 4* */* feZ4 J, ««* vera** :

Version •£ FBT5 u>cU ^mm< :
V3AX_FT

#13

1>^C patefe — '

T

*-— F*rwia4~ pateAeS Abooe

b I Z\pg

25

#13

Bc*^ *&K^£ <^r FiiTT(_

f. €ug Jw a.ecess tcruAin*. u>Am*K iVi OFFSET MOOS'

14>IS/ 77&«f 771* ••^ CkA*- Sfc<p ** AtofcMm. *r Ffc£ «#*4c

€>f u»eo **v«f STE113* scales.

5*^1/ £031 T £*<* £ ''cu.-

^5-4 53\ 3gt2S LtfZSi "mD *<«-*

^5^4 54\ 1*3 2 30XS* 'Wj ftcc*-*

&$±S&\ 743^ 7*<*44 "^/H-"

#S"4S * \ 7#*1 103 Z > "TOO Of^fe-z"

26

#13

c

DEMO OF MIXED FORTRAN/ SABR CODING, ALLOWED IN

c

OS-8. THIS

LETS US DO PRIMES THAT ARE "REAL-

c

CFLOATING NOSO

AND LARGER THAN 204T.

s

JMP tTAG

/JUMP

TO START OF PROGRAM

s

CPAGE 1?

/MAKE

SURE THERE* S ROOM FOR FOLLOWING

s

LINEFD*

212

-

s

MINUS6*

•6

s

COUNT*

9

s

EJECT*

6

/SUBR. FOR QUICK VERTICAL TAB

5

TAD

MIMUS6

s

DCA

COUNT

s

TAD

L1NEFD

s

LOOP!*

TLS

/TYPE IT

s

WAIT*

TSF

/DONE YET?

5

JMP WAIT

/NO

S

ISZ

COUNT

/YES* TONE 6 YET?

s

JMP

LOOP1

/NO

s

CLA

CLL

/YES* CLEAN OUT 212

s

JMP

I EJECT

/HARDWARE RETURN TO MAIN PROG

s

/GENERATES 2 INSTRUCTIONS

c

THE

ABOVE IS A PURELY LOCAL SUBROUTINE

c

ALL

OF IT CAS BE CUT OUT*

EVEN -JMP tTAG-* IF

c

YOU

AREN'T

INTERESTED IN -EJECT*. IF SO*

c

THEN THE TAG -tTAG- CAN GO* TOO. CF. BELOWs

s

tTAG*

CLA

CLL

s

TAD

C2330

/DENORMALIZE -2ER0-

s

DCA

\ZERO

/IST WORD OF -ZERO-

BACK TO FORTRANs

27

#13

C 00 A CR/LF TO START t

90 WRITS < 1,350)
KOU»TR«0

S JM5 EJECT /6 LINE FEEDS

1 WRITE < 1,100), ZERO,

C ••ZERO" IS A TAKE WRITE— SEE FORMAT

REAS C1#350)#BOTM
IF CBOTH -5.) 1,2,2

2 WRITE (1,206), ZERO,
READ C 1,350), TOP

IF C5.E6 - TOP) 2,3,3

3 CONTINUE

S JMS EJECT /6 LINE FEEDS

C SHENANIGANS TO HAKE "BOTH" AN ODD NUMBER!

BOTH * BOTH/ 2. ♦ ZERO
BOTH - 2.*B0TH ♦ I.

C END OF SHENANIGANS. INITIALIZE -VALUE"!

VALUE « BOTH - 2.

C — < OUTER LOOP! >

16 VALUE * VALUE + 2»

IP < VALUE - TOP) 11,11,90
11 FACTOR • 1.

C — — -< INNER LOOP! >—

20 FACTOR - FACTOR ♦ 2.
QUOT » VALUE/FACTOR
F1X1T • QUOT ♦ ZERO

IF CFIXIT - OUOT> 21,16,10

21 IF CQUOT - FACTOR) 50,16,20

C -—--..-.-—.-_ < LOOPS END HERE »<

28

#13

C ALL POSSIBLE FACTORS FAILED, SO IT'S PRIMES

50 KOUNTR*XQUNTR*l

VRITE C1#300^#KOUNTR* VALUE
60 TO 10

C INFINITE PROGRAM* TILL HALTED C »C V1U. DO IT).

100 FORMAT < 'BOTTOM VALUE* >3t **F0.0>
200 FORMAT C* TOP VALUE, t *>F«.0)

C THE SILLY F0.0 IS THE OHLY WAY TO SET IT TO WPE TEXT

C VHEM VE INHIBIT THE CR/LF BY USING A COMMA <SEE PROGRAM LINES

C 1 AND 2* PREV. PAGE).

300 rORMAT O4*2X*P10«0>
350 FORMAT €F10*0>

END